The ever-improving price-performance of microprocessors, random-access memory (RAM), and storage systems over the past decade has affected how computer software is developed. In the past, when hardware resources were more expensive, source code often was written in assembly language. Writing code in a low-level language was more time-consuming for developers, but resulted in somewhat more efficient and compact code. However, as a result of the improving price-performance of processors, memory, and storage, increasingly more programming is performed in high level languages, such as C/C++, Visual Basic, and others, to minimize the cost of software development.
Better tools for software developers have been created that make software creation more efficient and productive and take further advantage of the improved computing systems that are available. For example, static source code analysis tools help software developers to identify errors by deducing possible behavior of the source code. Some static source code analysis tools compile the code to identify syntax defects that the conventional compiler may not have detected that result in violation of programming language rules. Some static source code analysis tools do not include a compiler but, instead, intercept the output of an external compiler, parse the compiled code and analyze it. Once the static source code analysis tools have evaluated the source code for possible syntax errors, the representation of the source code generated by the code analyzer further allows the code to be evaluated for semantic problems by the simulator. Thus, static source code analysis tools help to detect syntax errors that may not have been detected by a compiler, as well as semantic errors that would not be detected by a compiler.
FIG. 1A shows a block diagram of a conventional (prior art) static source code analyzer 100a. Source code 102a prepared by a software developer is input to static source code analyzer 100a. The source code is first parsed by an input processor 104a, which ignores header blocks and comments, reducing the source code to a list of standard programming instructions 106a that are submitted to a simulator 108a. Simulator 108a identifies syntactic and semantic errors in the source code. For example, expressions that are misused, misspelled, or fail to contain proper arguments or delimiters are identified as syntactic errors. In addition, simulator 108a identifies errors that are other than literal or syntactic. For example, if the source code accesses memory that might not be properly initialized, simulator 108a identifies the error. For another example, if the source code requires a variable be initialized and within certain bounds, but the variable is not initialized or is invalid due to the value of the variable transcending the predetermined bounds, simulator 108a identifies also identifies the errors. Errors identified by simulator 108a are presented in an error report 110a that can be used by software developers to revise and repair their source code.
FIG. 1B shows an exemplary screen 120 from a prior art source code analyzer. In the source code analyzer, source code 122 submitted for analysis is viewable in a source code window 124, while error messages 126 are presented in an analysis window 128. Error messages 126 include correlations 130 with lines 132 in source code 122 to assist a software developer in correcting the error.
Static source code analyzers are tremendously helpful to software developers both in that they assist software developers in identifying problems that might interfere with compiling of the source code, or even if the source code compiles without incident, might cause the software to fail in operation. Static source code analyzers do not replace testing to determine if the resulting software functions as intended. However, by presenting developers with error messages 126 including correlations to specific lines 132 in source code 122, static source code analyzers allow developers to quickly address potential syntactic and semantic problems in their source code.
The accuracy of static source code analyzers depends on their ability to interpret the source code presented. As a result, some errors in the source code might be missed. In addition, if the static source code analyzer incorrectly interprets the source code being analyzed, false positives may be generated when the source code being evaluated is correct. Unfortunately, the occurrence of false positives amounts to noise that obscures error messages indicating actual errors in the source code. As a result, an actual error in the software code being analyzed may be overlooked by the software developer.
Other tools that are very helpful to software developers are software developer kits. Software developer kits are typically created for specific operating systems, such as Microsoft WINDOWS™, or computing or game platforms, such as the Microsoft XBOX™, to make software development easier by enabling access to previously-created software tools. These software development kits may include source code for prewritten routines that perform common functions likely to be included by developers in their code. By providing convenient access to such software routines, developers need not waste time rewriting common routines that already have been created.
Software development kits also may include application program interfaces or application programming interfaces (APIs) that can be accessed in the operating environment for which the developer is creating software. APIs can be used to invoke services to generate graphics, generate sounds, and any number of other functions. In addition, APIs that invoke differently implemented but functionally comparable services can be used to provide source code software portability between different platforms for which the source code can be compiled. Perhaps most significantly, APIs are useful for providing an interface between high level language source code and lower level utilities that operate more directly with the hardware devices of the operating environment.
APIs are often distributed separately or as part of a software development kit, in a collection of binary libraries. Typically, the source code used to create the APIs are not distributed or otherwise made available to developers. The source code is not made available to protect various proprietary concerns of the developers of the operating environment. However, even though the source code implementation of the API is not made available, documentation or other information may be made available with the software development kit that explains the operation of the API, the proper syntax for invoking the API, arguments to be passed to the API, and characteristics of values returned by the API.
Unfortunately, submitting source code that invokes one or more APIs to a static source code analyzer may result in the generation of a number of errors. As described above, a source code analyzer is only accurate to the extent that it is configured to understand the source code. Thus, a static source code analyzer may be unable to analyze an API signature, because the static source code analyzer is only presented with the API signature and cannot access the source code implementation of the API.
As shown in the prior art example of FIG. 1C, when analyzing source code 102c, input processor 104c of static source code analyzer 100c will recognize API signature(s) 152 as distinct from standard programming instructions 106c. API signature(s) 152 may be regarded as a syntax error in error report 110c, because the API signature represents a non-standard expression. Alternatively, for example in C++, an “extern” designation can be appended to API signature(s) 152, which will prevent simulator 108c from attempting to evaluate the semantics of API signature(s) 152. Without the source code implementation of the API, a static source code analyzer may be able to evaluate the syntax of an API call by determining whether appropriate arguments are passed to the API in accordance with the API signature. However, without the source code, a static source code analyzer cannot semantically evaluate API signature(s) 152, their behavior, of their effect on source code that invokes API signature(s) 152. Upon encountering the “extern” designation, the static source code analyzer makes no attempt to semantically evaluate the expression that follows.
Without access to the source code implementation of the API, the static source code analyzer cannot determine what effect the API might have, for example, on arguments passed to the API. As a result, static source code analyzer 108c may generate an error message with regard to a problem with a variable when, in fact, that problem is actually related to the API. As a result, inclusion of API signatures in source code may result in a great deal of false positive error messages or noise being generated by the source code analyzer that may, unfortunately, divert attention away from actual true error messages. In addition, because the source code analyzer may not be able to evaluate an API call or it effects, the source code analyzer will not be able to detect errors resulting from such an API call. The API may perform an operation on an argument that was passed to it that will result in an illegal operation at some subsequent point in the source code. Thus, if the source code analyzer is incapable of evaluating the operation of the API, the source code analyzer may fail to detect related errors in the source code.
It would therefore be desirable to provide a method and system that is able to evaluate API calls, even without having access to the source code implementation of the API.